United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
I nilid Stall-, Patent and Trademark Office 

Address: COMMISSIONER FOR PATENTS 



APPLICATION NO. 



10/692,097 



FILING DATE 



10/22/2002 



FIRST NAMED INVENTOR 



Alexander E. Vaschillo 



47973 7590 02/28/2011 

WORKMAN NYDEGGER/MICROSOFT 
1000 EAGLE GATE TOWER 
60 EAST SOUTH TEMPLE 
SALT LAKE CITY, UT 841 1 1 



ATTORNEY DOCKET NO. CONFIRMATION NO. 



MACILWINEN, JOHN MOORE JAIN 



PAPER NUMBER 



DELIVERY MODE 



Please find below and/or attached an Office communication concerning this application or proceeding. 

The time period for reply, if any, is set in the attached communication. 



PTOL-90A (Rev. 04/07) 





Application No. 

10/692,097 


Applicant(s) 

VASCHILLO ET AL. 


Examiner 

JOHN M. MACILWINEN 


Art Unit 

2442 





- The MAILING DATE of this communication appears on the cover sheet with the correspondence address — 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 )IEI Responsive to communication(s) filed on 01 October 2010 . 
2a)D This action is FINAL. 2b)^ This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 1 1 , 453 O.G. 213. 

Disposition of Claims 

4) |EI Claim(s) 1,3-7,9, 10, 12-16, 18-32,34-36,44,45 and 48-50 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) [X] Claim(s) 1,3-7,9, 10, 12-16, 18-32,34-36,44,45 and 48-50 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) El The specification is objected to by the Examiner. 

10) D The drawing(s) filed on is/are: a)Q accepted or b)Q objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

1 1) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. §119 

12) Q Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 
a)DAII b)D Some * c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

20 Certified copies of the priority documents have been received in Application No. . 

3.D Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attachment(s) 

_3 Notice of References Cited (PTO-892) 4) D Interview Summary (PTO-413) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) Paper No(s)/Mail Date. . 

El Information Disclosure Statement(s) (PTO/SB/08) 5) □ Notice of Informal Patent Application 

Paper No(s)/Mail Date 7/27/2010 . 6) □ Other: . 

PTOL-326 (Rev. 08-06) Office Action Summary Part of Paper No./Mail Date 201 10222 



Application/Control Number: 10/692,097 Page 2 

Art Unit: 2442 

DETAILED ACTION 
Response to Arguments 

1. Applicant's arguments filed 10/01/2010 have been fully considered. 

2. On page 23, Applicant asserts that the cited prior art 
"fails to teach or suggest: 

an act of making the message item compatible with the plurality of 
different message protocols, including for each different message protocol in the 
plurality of different message protocols.... 

an act of assigning values to at least one general property that is common 
between two different messaging extensions." 

Applicant's arguments here and on the first half of page 24 fail to comply with 37 
CFR 1 .1 1 1 (b) because they amount to a general allegation that the claims define a 
patentable invention without specifically pointing out how the language of the claims 
patentably distinguishes them from the references. 

3. Applicant argues on page 24 that the claims have also been amended to 
address any issues under 35 USC 112, second paragraph. Though Applicant's claims 
no longer recite the language regarding "simultaneously", which was addressed in the 
Final Rejection mailed 05/25/2010, Applicants now claim a message that is "natively 
compatible". Applicant's Specification, however, lacks support for such language. This 
issue is addressed in further detail below. 
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Claim Objections 

4. Claim 1 is objected to because of the following informalities - 
Lines 4-5 recites: 

"and natively compatible a with a...." (emphasis added). 

5. Claim 15 is objected to because of the following informalities - 
Line 3 recites: 

"comprises on act of retrieving..." (emphasis added). 
Appropriate correction is required. 

Specification 

6. The specification is objected to as failing to provide proper antecedent basis for 
the claimed subject matter for the reasons given below in the 35 USC 1 1 2 written 
description rejection. See 37 CFR 1.75(d)(1) and MPEP § 608.01 (o). 

Claim Rejections - 35 USC §112 

7. The following is a quotation of the first paragraph of 35 U.S.C. 1 1 2: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

8. Claims 1 and 44 are rejected under 35 U.S.C. 1 1 2, first paragraph, as failing to 
comply with the written description requirement. The claim(s) contains subject matter 
which was not described in the specification in such a way as to reasonably convey to 
one skilled in the relevant art that the inventor(s), at the time the application was filed, 
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had possession of the claimed invention. Said claims recite a message item that is 
"natively compatible" with a plurality of different message protocols and applications. 

9. Claims 6 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply 
with the written description requirement. The claim contains subject matter which was 
not described in the specification in such a way as to reasonably convey to one skilled 
in the relevant art that the inventors, at the time the application was filed, had 
possession of the claimed invention. Said claim recite a message item has an 
"attaching an NNTP protocol extension ... while the POP3 protocol extension also 
remains attached..." (emphasis added). 

10. Claims 1 , 4, 5, 6, 7, 9, 1 0, 1 2, 1 5 and 45 are rejected under 35 U.S.C. 1 1 2, first 
paragraph, as failing to comply with the written description requirement. The claim 
contains subject matter which was not described in the specification in such a way as to 
reasonably convey to one skilled in the relevant art that the inventors, at the time the 
application was filed, had possession of the claimed invention. Each of said claims 
references "attaching" data from a schema to the message item. 

For example, claim 1 recites, on pg. 2: 

"attaching protocol specific data fields from at least one protocol specific 

extension schema" 
and claim 1 continues on pg. 3 to recite: 

"attaching application specific data fields from at least one application 

specific extension". 
Claim 4 twice recites: 



Application/Control Number: 10/692,097 Page 5 

Art Unit: 2442 

"attaching at least one protocol specific message extension". 
Claim 5 recites: 

"attaching at least one application specific extension" and 

"attaching a POP3 protocol extension". 
Claim 6 recites: 

"attaching at least one application specific extension" and 

"attaching an NNTP protocol extension" and 

"while the POP3 extension also remains attached". 
Claim 7 recites: 

"attaching at least one protocol specific extension" and 

"a5ttaching a community news protocol extension". 
Claim 9 recites: 

"attaching at least one application specific extension" and 

"attaching at least one application extension". 
Claim 10 recites: 

"attaching at least one application extension" and 

"attaching a Microsoft. RTM. Outlook. RTM. Express application extension". 
Claim 12 recites: 

"an act of retrieving at leas tone value from one or more data fields 

attached to the message". 
Claim 15 recites: 

"other data fields attached to the message". 
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Claim 44 recites, on pg. 18: 

"attach protocol specific data fields" 

and continues on pg. 19 to recite: 

"attach application specific data fields". 

Applicant's Specification does discuss the concept of messages having 
attachments as well as attachments having an "attachment schema" associated with 
said attachment. Said "attachment schema" is discussed in [56] on page 30 as a 
schema which describes a messages attachment, rather than what Applicant's claim 
language appears to recite, which corresponds instead to a schema attached to a 
message. Paragraphs [52-55] on pages 22 - 29, which immediately precedes the above 
discussed "attachment schema" discuss other types of schema, including a "contact 
schema", a "folder schema", etc. To compare [52-55] to [56], [52-55] of Applicant's 
Specification supports said schema describing, for example, a "folder" but does not 
support, for example, a schema being a "folder" just as [56] supports a schema that 
describes an "attachment" but does not support a schema being an "attachment" or 
being "attached". 

That is to say that no recitation is made regarding "attaching a schema" or 
"attaching data fields" (or other equivalent language) to a message. 

Rather, Applicant's Specification recites that such items are "assigned" to a 
message, which is supported by Applicant's Specification and corresponds to the 
language utilized in the original claims. 

11. The following is a quotation of the second paragraph of 35 U.S. C. 112: 
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The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

12. Claims 1 , 5, 6, 9 and 44 are rejected under 35 U.S.C. 1 1 2, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 

13. Regarding claims 1 and 44, said claims recite a message item that is "natively 
compatible" with a plurality of different message protocols and applications. It is unclear 
the scope Applicant intends to claim with the language "natively compatible"; said lack 
of clarity is exacerbated by the lack of written description in Applicant's Specification for 
said subject matter. 

Claims 1 and 44 further recite storing and accessing messages "with increased 
efficiency". The precise meets and bounds of said claim language is unclear as it is not 
clear what Applicant intends to use as a gauge or baseline measurement/criteria to 
determine when precisely efficiency would reach the point of being considered 
"increased". 

14. Regarding claim 5, lines 1 - 2 recite 

"wherein the act of attaching at least one application specific extension" 
but the claim then concludes by transitioning to discussing a 
"protocol extension" (emphasis added). 

15. Regarding claim 6, lines 1 - 2 recite 

"wherein the act of attaching at least one application specific extension" 
but the claim then concludes by transitioning to discussing various types of 
"protocol extensions] (emphasis added). 
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16. Regarding claim 9, line 1 recites that the claim is further defining 

"attaching at lest one application specific extension schema" and 
lines 6 - 7 state that it is directed to defining 

"attaching at lest one application extension to the message item". 
However, lines 7-8 continue to recite 

"the at least one more application extension..." (emphasis added). 

17. In order to perform a complete examination, the above claims have been 
interpreted broadly. 

Claim Rejections - 35 USC § 102 

18. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in 
public use or on sale in this country, more than one year prior to the date of application for patent in 
the United States. 

19. Claims 1 , 3 - 7, 9, 1 8 - 22 and 44 are rejected under 35 U.S.C. 1 02(b) as being 
anticipated by Guck (5,794,039), hereafter Guckl (where 5,91 1 ,776, hereafter Guck2 
and 5,848,415, hereafter Guck3, are each incorporated by reference into Guckl). 

20. Regarding claim 1 , Guck shows a computer system that is network connectable 
along with one or more other computer systems to a network, the computer system 
including a processor and system memory, a method for formulating an electronic 
message that is natively compatible with a plurality of different message protocols 
{Guckl, col. 1 lines 30-38, col. 5 lines 38 - 42, col. 6 lines 54 - 58) and natively 
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compatible a with a plurality of different messaging applications {Guckl, col. 6 lines 58 
-60, col. 7 line 1, col. 7 lines 60 - 65, col. 9 lines 25 - 30) and can be stored and 
accessed with increased efficiency (Guckl, col. 1 lines 55 - 67, col. 6 lines 3- 15, col. 
6 lines 41-43 and Guck2, col. 15 lines 39 - 46), the method comprising: 

an act of the processor creating a message item representing the 
electronic message in accordance with a message schema (Guck2, col. 14 lines 14- 
35, col. 15 lines 14 - 28), the message item having one or more general properties 
common to the plurality of different message protocols and common to the plurality of 
different message applications (Guckl, col. 10 lines 48 - 50, col. 7 lines 60 - 61), the 
message item creation including: 

an act of assigning a primary type to the message item, the primary 
type indicating a primary behavior of a plurality of content portions linked 
to the message item (Guck2, col. 15 lines 27- 45, col. 14 lines 16 - 16); 

an act of making the message item compatible with the plurality of 
different message protocols, including for each different message protocol 
in the plurality of different message protocols (Guckl, col. 6 lines 42- 58, 
Guck3, col. 4 lines 35 - 44, col. 6 lines 20 - 34, col. 8 lines 2- 13): 

an act of attaching protocol specific data fields from at least 
one protocol specific extension schema to the message item 
(Guckl, col. 5 lines 49-52, col. 10 lines 55- 67, col. 9 lines 47 - 
57) to make the plurality of linked content portions compatible with 
the message protocol, each protocol specific extension accounting 
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for any properties that are not common between the plurality of 
different message protocols {Guck3, col. 10 lines 11-25); and 

an act of assigning values to the protocol specific data fields 
(Guckl, col. 9 line 65- col. 10 line 4, Guck2, col. 15 lines 63 - 65, 
Guck3, col. 8 lines 52-55) ; 

an act of making the message item compatible with the 
plurality of different message applications, including for each 
different message application in the plurality of different message 
applications (Guckl, col. 9 lines 30- 35, col. 10 lines 48 - 50); 

an act of attaching application specific data fields from at 
least one application specific extension to the message item to 
make the plurality of linked content portions compatible with the 
message application, each application specific extension schema 
accounting for properties that are not common between the plurality 
of different message applications (Guck2, col. 2 lines 39 - 65, col. 
1 1 line 65 - col. 12 line 5, col. 15 lines 45-67), 

an act of assigning values to properties of the at least one 
application specific extensions {Guckl, col. 9 lines 28 - 48, Guck2, 
col. 7 lines 14 - 27, col. 13 lines 55-61, col. 15 lines 6s 65); and 

an act of assigning values to at least one general property 
that is common between two different messaging extensions 
(Guck2, col. 7 lines 58 - 62, col. 10 lines 48 - 50). 
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21. Regarding claim 3, Guck further shows wherein the an act of assigning a primary 
type to the created message item comprises an act of assigning a primary type to the 
created message item, the primary type being selected from among electronic mail 
message, instant message, fax message, voice message, news group posting (Guckl, 
col. 10 lines 48 - 49). 

22. Regarding claim 4, Guck further shows wherein the act of attaching at least one 
protocol specific message extension to the message item comprises an act of attaching 
at least one protocol specific extension to the message item, the at least one protocol 
specific message extension being selected from among: among electronic mail protocol 
extensions, instant messaging protocol extensions, fax protocol extensions, voice 
message protocol extensions and, news group posting protocol extensions (Guckl, col. 
9 lines 47- 58, Guck3, col. 12 lines 32 - 44). 

23. Regarding claim 5, Guck further shows wherein the act of attaching at least one 
application specific extension to the message item comprises an act of attaching a 
POP3 protocol extension to the message item, the POP3 protocol extension from an 
electronic mail POP3 extension schema (Guck3, col. 6 lines 20 - 35, col. 9 lines 3 - 35, 
Fig. 1 item 56). 

24. Regarding claim 6, Guck further shows wherein the act of attaching at least one 
application specific extension to the message item comprises an act of attaching an 
NNTP protocol extension from the electronic mail NNTP extension schema to the 
message item (Guckl, col. 9 lines 50-59, col. 10 line 63- col. 1 1 line 4 and col. 14 
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lines 38- 40, Guck3 col. 9 lines 1 - 5), while the POP3 protocol extension also remains 
attached to the message item {Guck2, col. 5 lines 7- 10 and col. 10 lines 10 - 17). 

25. Regarding claim 7, Guck further shows wherein the act of attaching at least one 
protocol specific extension to the message item comprises an act of (Guckl, col. 5 lines 
49 - 52, col. 9 lines 47- 57, col. 10 lines 55- 67 and Guck3, col. 10 lines 11-25) 
attaching a community news protocol extension to the message item, the community 
news protocol extension from an electronic mail community news extension schema 
{Guckl, col. 9 lines 50 - 59, col. 10 line 63 - col. 1 1 line 4, col. 14 lines 38 - 40, Guck3, 
col. 9 lines 1-5). 

26. Regarding claim 9, Guck further shows wherein the act of attaching at least one 
application specific extension to the message item comprises an act of attaching at 
least one application extension to the message item, the at least one more application 
extension being selected from among: electronic mail application extensions, instant 
messaging application extensions, fax application extensions, voice message 
application extensions, and news group posting application extensions {Guck2, col. 15 
lines 14 - 67, Guck3, col. 5 lines 5 - 10). 

27. Regarding claim 1 8, Guck further shows wherein the act of creating a message 
item representing an electronic message comprises an act of creating a message item 
including: 

a general properties field representing common electronic message properties 
that are common to a plurality of different types of message protocols and a plurality of 
different types of message applications {Guckl, col. 7 lines 58- 61, col. 10 lines 48 - 
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50); and 

at least one protocol specific property field, the at least one protocol specific 
property field representing one or more protocol specific message properties that 
correspond to a specific message protocol, the specific message protocol being 
selecting from among the plurality of different types of message protocols that have the 
common electronic message properties represented in the general properties field in 
common (Guck2, col. 14 lines 15 - 27). 

28. Regarding claim 1 9, Guck further shows wherein the at least one protocol 
specific property field comprises: 

a protocol specific property field representing one or more protocol specific 
message properties that correspond to one of an electronic mail protocol, an instant 
messaging protocol, a fax protocol, a voice message protocol, or a news group protocol 
{Guckl, col. 9 lines 20-35). 

29. Regarding claim 20, Guck further shows wherein the act of creating a message 
item further comprises an act of creating a message item including: 

at least one application specific property field, the at least one application specific 
property field representing one or more application specific electronic message 
properties that correspond to a specific message application, the specific message 
application being selecting from among the plurality of different types of message 
applications that have the common electronic message properties represented in the 
general properties field in common {Guckl, col. 9 lines 20 - 35, Guck2, col. 14 lines 15 
- 25, col. 15 lines 50-55). 
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30. Regarding claim 21 , Guck further shows wherein the act of creating a message 
item representing an electronic message comprises an act of creating a data structure 
an comprising including: 

a general properties field representing common electronic message properties 
that are common to a plurality of different types of message protocols and a plurality of 
different types of message applications (Guckl, col. 9 lines 20-35, Guck2, col. 14 lines 
15 - 25, col. 15 lines 50 - 55); and 

at least one application specific property field, the at least one application specific 
property field representing one or more application specific electronic message 
properties that correspond to a specific message application, the specific message 
application being selecting from among the plurality of different types of message 
applications that have the common electronic message properties represented in the 
general properties field in common (Guckl, col. 9 lines 20 - 35, Guck2, col. 14 lines 15 
- 25, col. 15 lines 50 - 55). 

31. Regarding claim 22, Guck further shows wherein the at least one application 
specific property field comprises: 

an application specific property field representing one or more application 
specific message properties that correspond to one of an electronic mail application, an 
instant messaging application, a fax application, a voice message application, or a news 
group application (Guck2, col. 15 lines 34 - 35, col. 15 lines 40 - 55). 

32. Regarding claim 44, Guck shows a computer program product for use in a 
computer system that is network connectable along with one or more other computer 
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systems to a network, the computer program product for implementing a method for 
formulating an electronic message that is natively compatible with a plurality of different 
message protocols {Guckl, col. 1 lines 30- 38, col. 5 lines 38 - 42, col. 6 lines 54 - 58) 
and natively compatible a with a plurality of different messaging applications {Guckl, 
col. 6 lines 58 -60, col. 7 line 1, col. 7 lines 60 - 65, col. 9 lines 25 - 30) and can be 
stored and accessed with increased efficiency {Guckl, col. 1 lines 55- 67, col. 6 lines 3 
- 15, col. 6 lines 41-43 and Guck2, col. 15 lines 39 - 46), the computer program 
product comprising one or more computer storage devices having stored thereon 
computer executable instructions that, when executed by a processor, cause the 
computer to perform the following {Guck2, col. 2 lines 20-32, col. 2 line 67- col. 3 line 
10, col. 6 lines 42 - 48): 

create a message item representing the electronic message in accordance with a 
message schema {Guck2, col. 14 lines 14- 35, col. 15 lines 14 - 28), the message item 
having one or more general properties common to the plurality of different message 
protocols and common to the plurality of different message applications {Guckl, col. 10 
lines 48 - 50, col. 7 lines 60 - 61), the message item creation including: 

assign a primary type to the message item, the primary 
type indicating a primary behavior of a plurality of content portions linked 
to the message item {Guck2, col. 15 lines 27- 45, col. 14 lines 16 - 16); 

make the message item compatible with the plurality of 
different message protocols, including for each different message protocol 
in the plurality of different message protocols {Guckl, col. 6 lines 42- 58, 
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Guck3, col. 4 lines 35 - 44, col. 6 lines 20 - 34, col. 8 lines 2- 13): 

attach protocol specific data fields from at least 
one protocol specific extension schema to the message item 
{Guckl, col. 5 lines 49 - 52, col. 10 lines 55 - 67, col. 9 lines 47 - 
57) to make the plurality of linked content portions compatible with 
the message protocol, each protocol specific extension accounting 
for any properties that are not common between the plurality of 
different message protocols {Guck3, col. 10 lines 11-25); and 

assign values to the protocol specific data fields 
{Guckl, col. 9 line 65- col. 10 line 4, Guck2, col. 15 lines 63 - 65, 
Guck3, col. 8 lines 52-55); 

make the message item compatible with the 
plurality of different message applications, including for each 
different message application in the plurality of different message 
applications {Guckl, col. 9 lines 30-35, col. 10 lines 48 - 50); 

attach application specific data fields from at 
least one application specific extension to the message item to 
make the plurality of linked content portions compatible with the 
message application, each application specific extension schema 
accounting for properties that are not common between the plurality 
of different message applications {Guck2, col. 2 lines 39 - 65, col. 
1 1 line 65 - col. 12 line 5, col. 15 lines 45-67), 
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assign values to properties of the at least one 
application specific extensions {Guckl, col. 9 lines 28 - 48, Guck2, 
col. 7 lines 14 - 27, col. 13 lines 55-61, col. 15 lines 6s 65); and 

an act of assigning values to at least one general property 
that is common between two different messaging extensions 
{Guck2, col. 7 lines 58 - 62, col. 10 lines 48 - 50). 

Claim Rejections - 35 USC § 103 

33. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

34. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Guck in 
view of Outlook (Outlook Express EML, Computing.net, December 2002). 

35. Regarding claim 1 0, Guck shows claim 9. 

Guck does not show wherein the act of assigning at least one application 
extension to the message item comprises an act of attaching a Microsoft. RTM. 
Outlook. RTM. Express application extension to the message item. 

Outlook shows assigning at least one application extension to the message item 
comprises an act of attaching a Microsoft. RTM. Outlook. RTM. Express application 
extension to the message item {pgs. 1 - 5). 

It would have been obvious to one of ordinary skill in the art at the time of the 
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invention to modify the disclosure of Guck with that of Outlook in order to support a 
commonly utilized messaging format (Outlook, pgs. 1 - 5). 

36. Claims 23, 24, 34 and 35 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Guck in view of Luzeski (US 6,404,762 B1 ), Lee (US 6,21 2,553 B1 ) 
and Kennedy (6,134,582). 

37. Regarding claim 23, Guck shows claim 1 . 

Guck does not show all of: one or more computer-readable media having stored 
thereon a data structure for representing an electronic message, the data structure 
comprising: 

an ID field representing an identifier that identifies the electronic message within 
an message database; 

a primary type field representing a primary message type of the electronic 
message identified by the identifier represented in the ID field, the primary message 
type implying a behavior of the electronic message; 

at least one MessageParticipant relationship field representing links to one or 
more message participants associated with the electronic message identified by the 
identifier represented in the ID field; 

at least one MessageContents relationship field representing links to one or more 
portions of message content corresponding to the electronic message electronic 
message identified by the identifier represented in the ID field. 

Luzeski shows one or more computer-readable media having stored thereon a 
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data structure for representing an electronic message, the data structure comprising: 
an ID field representing an identifier that identifies the electronic message within 

an message database {col. 15 lines 60- 61 and col. 16 lines 18 - 20); 

a primary type field representing a primary message type of the electronic 

message identified by the identifier represented in the ID field, the primary message 

type implying a behavior of the electronic message {col. 15 lines 25- 31 and col. 16 line 

5); 

at least one MessageParticipant relationship field representing links to one or 
more message participants associated with the electronic message identified by the 
identifier represented in the ID field (col. 15 lines 65-66 and col. 16 line 9); 

at least one MessageContents relationship field representing links to one or more 
portions of message content corresponding to the electronic message electronic 
message identified by the identifier represented in the ID field {col. 16 line 10 and col. 
16 lines 64 - 68). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck with that of Luzeski in order to provide for a 
simplified messaging environment {Luzeski, col. 4 lines 40- 50). 

Guck in view of Luzeski do not show at least one sent message folder 
relationship field representing links to one or more message folders the electronic 
message identified by the identifier represented in the ID field is to be moved to after 
being submitted for delivery; and 

a download state field representing a download state of the electronic message 
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identified by the identifier represented in the ID field. 

Lee shows at least one sent message folder relationship field representing links 
to one or more message folders the electronic message identified by the identifier 
represented in the ID field is to be moved to after being submitted for delivery (col. 32 
lines 50 - 65). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view of Luzeski with that of Lee in order to 
ensure that a users sent messages are properly organized and stored. 

Guck in view of Luzeski and Lee do not show a download state field representing 
a download state of the electronic message identified by the identifier represented in the 
ID field. 

Kennedy shows a download state field representing a download state of the 
electronic message identified by the identifier represented in the ID field (Abstract). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view of Luzeski and Lee with that of 
Kennedy in order to better track a messages retrieval status. 

38. Regarding claim 24, Guck in view of Luzeski, Lee and Kennedy further show 
message status field representing the status of the electronic message identified by the 
identifier represented in the ID field (Lee, Fig. 11). 

39. Regarding claim 34, Guck shows claim 3. 

Guck does not show all of: a primary type field defining a format for representing 
a primary message type corresponding to an electronic message, the primary message 
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type implying a behavior of the electronic message, 

a participants relationship field defining a format for representing links to 
message participants, the message participants being associated with the electronic 
message having a primary message type defined in accordance with the primary 
message type format in the primary type field, 

a contents relationship field defining a format for representing links to one or 
more portions of message content, the one or more portions of message content 
corresponding to the electronic message electronic message having a primary message 
type defined in accordance with the primary message type format in the primary type 
field. 

Luzeski shows a primary type field defining a format for representing a primary 
message type corresponding to an electronic message, the primary message type 
implying a behavior of the electronic message (col. 15 lines 25 - 31 and col. 16 line 5) 

a participants relationship field defining a format for representing links to 
message participants, the message participants being associated with the electronic 
message having a primary message type defined in accordance with the primary 
message type format in the primary type field {col. 15 lines 65 - 66 and col. 16 line 9) 

a contents relationship field defining a format for representing links to one or 
more portions of message content, the one or more portions of message content 
corresponding to the electronic message electronic message having a primary message 
type defined in accordance with the primary message type format in the primary type 
field (col. 16 line 10 and col. 16 lines 64 - 68). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck with that of Luzeski in order to provide for a 
simplified messaging environment {Luzeski, col. 4 lines 40- 50). 

Guck in view of Luzeski do not show at least one sent message folder 
relationship field representing links to one or more message folders the electronic 
message identified by the identifier represented in the ID field is to be moved to after 
being submitted for delivery; and 

a download state field representing a download state of the electronic message 
identified by the identifier represented in the ID field. 

Lee shows at least one sent message folder relationship field representing links 
to one or more message folders the electronic message identified by the identifier 
represented in the ID field is to be moved to after being submitted for delivery {col. 32 
lines 50-65). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view of Luzeski with that of Lee in order to 
ensure that a users sent messages are properly organized and stored. 

Guck in view of Luzeski and Lee do not show a download state field representing 
a download state of the electronic message identified by the identifier represented in the 
ID field. 

Kennedy shows a download state field representing a download state of the 
electronic message identified by the identifier represented in the ID field (Abstract). 
It would have been obvious to one of ordinary skill in the art at the time of the 
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invention to modify the disclosure of Guck in view of Luzeski and Lee with that of 
Kennedy in order to better track a messages retrieval status. 

40. Regarding claim 35, Guck in view of Luzeski, Lee and Kennedy further show a 
message status field defining a format for representing the status of the electronic 
message having a primary message type defined in accordance with the primary 
message type format in the primary type field, the message schema including or 
referring to a message status schema that defines the format for representing the status 
of the electronic message (Lee, Fig. 11). 

41. Claims 25 and 36 are rejected under 35 U.S.C. 1 03(a) as being unpatentable 
over Guck in view of Luzeski, Lee and Kennedy, further in view of Almond (6,1 12,024) . 

42. Regarding claim 25, Guck in view of Luzeski Lee and Kennedy show claim 24, 
including wherein the message status field is comprised of: 

an IsRead field representing an indication of whether or not the electronic 
message in identified by the identifier represented in the ID field has been marked as 
read {Lee, Figs. 1 1 and 14); and 

a SendStatus field representing an indication of the send status of the electronic 
message identified by the identifier represented in the ID field (Lee, Fig. 11 and col. 32 
lines 50 - 55). 

Guck in view of Luzeski, Lee and Kennedy do not show a LastActionTaken field 
representing an indication of the last action that was taken on the electronic message 
identified by the identifier represented in the ID field; 
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a LastActionTime field representing the time that the last action indicated in the 
LastActionTaken field was taken; 

a LastActionType field representing the type of that last action taken on the 
electronic message identified by the identifier represented in the ID field. 

Almond shows a LastActionTaken field representing an indication of the last 
action that was taken on the electronic message identified by the identifier represented 
in the ID field; 

a LastActionTime field representing the time that the last action indicated in the 
LastActionTaken field was taken; 

a LastActionType field representing the type of that last action taken on the 
electronic message identified by the identifier represented in the ID field (Fig. 7C). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view Luzeski, Lee and Kennedy with that 
of Almond in order to better manage document changes, enabling additional document 
management options (Almond, Abstract, cols. 1 - 2). 

43. Regarding claim 36, Guck in view of Luzeski Lee and Kennedy show claim 35, 
including wherein the message status field is comprised of: 

an IsRead field representing an indication of whether or not the electronic 
message in identified by the identifier represented in the ID field has been marked as 
read (Lee, Figs. 1 1 and 14); and 

a SendStatus field representing an indication of the send status of the electronic 
message identified by the identifier represented in the ID field (Lee, Fig. 1 1 and col. 32 
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lines 50 - 55). 

Guck in view of Luzeski, Lee and Kennedy do not show a LastActionTaken field 
representing an indication of the last action that was taken on the electronic message 
identified by the identifier represented in the ID field; 

a LastActionTime field representing the time that the last action indicated in the 
LastActionTaken field was taken; 

a LastActionType field representing the type of that last action taken on the 
electronic message identified by the identifier represented in the ID field. 

Almond shows a LastActionTaken field representing an indication of the last 
action that was taken on the electronic message identified by the identifier represented 
in the ID field; 

a LastActionTime field representing the time that the last action indicated in the 
LastActionTaken field was taken; 

a LastActionType field representing the type of that last action taken on the 
electronic message identified by the identifier represented in the ID field {Fig. 7C). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view Luzeski, Lee and Kennedy with that 
of Almond in order to better manage document changes, enabling additional document 
management options {Almond, Abstract, cols. 1 - 2). 

44. Claims 26 and 27 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Guck in view of RFC 2046 (MIME Part Two: Media Types, November 1 996). 
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45. Regarding claim 26, Guck shows one or more computer-readable media having 
stored thereon a data structure representing a portion of message content, the data 
structure comprising: 

an electronic message relationship field representing a link to an electronic 
message, the link indicating that the portion of message content is associated with an 
electronic message {Guckl, col. 7 lines 8- 30, col. 9 lines 20 -47 and col. 12 lines 18 
- 67); and 

a content type field representing a content type corresponding to the portion of 
message content (Guck2, col. 16 lines 12-25). 

Guck does not show an order field representing an order value, the order value 
indicating how the portion of message content is to be ordered with respect to other 
portions of message content that are also associated with the electronic message; and 

a content properties field representing additional properties of the content type 
represented in the content type field. 

RFC 2046 shows an order field representing an order value, the order value 
indicating how the portion of message content is to be ordered with respect to other 
portions of message content that are also associated with the electronic message; and 

a content properties field representing additional properties of the content type 
represented in the content type field (5.2.2.2). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck with that of RFC 2046 in order to utilize a 
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well-known established and standardized protocol as well as to follow the practices 
encouraged by Guck (Guck2, col. 2 lines 60- 66). 

46. Regarding claim 27, Guck in view of RFC 2046 further show wherein the content 
properties field comprises: an attachment type field representing an attachment type of 
the portion of message content (RFC 2046, 5.2.2.2). 

47. Claim 28 is rejected under 35 U.S.C. 103(a) as being unpatentable over Guck in 
view of RFC 2046 as applied to claims 26 and 37 above, further in view of RFC 2017 
(Definition of the URL MIME External-Body Access-Type, October 1996). 

48. Regarding claim 28, Guck in view of RFC 2046 show claim 26. 

Guck in view of RFC 2046 do not show a MIME URL field representing a link to a 
MIME path that corresponds to the portion of message content. 

RFC 2017 shows a MIME URL field representing a link to a MIME path that 
corresponds to the portion of message content {pgs. 1 - 4). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view of RFC 2046 with that of RFC 2017 in 
order to utilize a well-known established and standardized protocol. 

49. Claim 29 is rejected under 35 U.S.C. 103(a) as being unpatentable over Guck in 
view of Chao (US 2004/01 28355 A1 ). 

50. Regarding claim 29, Guck shows one or more computer-readable media having 
stored thereon a data structure for representing a message attachment, the data 
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structure comprising: 

an electronic message relationship field representing a link to a message item, 
the link indicating that the message attachment is associated with the message item 
( Guckl, col. 7 lines 8 - 30, col. 9 lines 20-47 and col. 12 lines 18-67); 

a type field representing a message type of the electronic message linked to by 
the link represented in the electronic message link field, the message type implying a 
behavior of the electronic message (Guck2, col. 14 lines 15-25 and col. 15 lines 50 - 
55); 

and an attachment state field representing the type and behavior of the message 
attachment {Guck2, col. 16 lines 12-25). 

Guck does not show an IsPinned field representing the deletion status of the 
message attachment with respect to the electronic message linked to by the link 
represented in the electronic message link field; and 

an IsTrusted field representing trust information related to the message 
attachment. 

Chao shows an IsPinned field representing the deletion status of the message 
attachment with respect to the electronic message linked to by the link represented in 
the electronic message link field {[29]) and 

an IsTrusted field representing trust information related to the message 
attachment {[12, 40-43] and Fig. 6). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck with that of Chao in order to better manage 
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and classify messages {Chao, [11]). 
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51. Claims 30 and 31 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Guck in view of Chao as applied to claims 29 and 40 above, and further in view of 
RFC 2017. 

52. Regarding claim 30, Guck in view of Chao show claim 29. 

Guck in view of Chao do not show an attachment source relationship field 
representing a link to a database item where the message attachment was accessed. 

RFC 201 7 shows an attachment source relationship field representing a link to a 
database item where the message attachment was accessed (pgr. 1). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view of Chao with that of RFC 201 7 in 
order to utilize a well-known established and standardized protocol. 

53. Regarding claim 31 , Guck in view of Chao and RFC 201 7 further show a saved 
from relationship field representing a link to the message attachment {RFC 2017, pg. 1). 

54. Claim 32 is rejected under 35 U.S.C. 103(a) as being unpatentable over Guck in 
view of NNTP (S. Barber, January 2002). 

55. Regarding claim 32, Guck shows one or more computer-readable media having 
stored thereon a data structure representing a community news folder, the data 
structure comprising: 

a communities last refresh field representing the last time the community 
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dynamic properties of the news group community including the collection of 
synchronized article IDs represented in the community range field was refreshed 
{Guckl, col. 16 lines 8-12 and col. 8 lines 35 - 60). 

Guck does not show a community range field representing a collection of article 
ID ranges from a news group community that have been synchronized with community 
header properties; 

a low article ID field representing a low article ID included the a collection of 
synchronized article ID ranges represented in the community range field; and 

a high article ID field representing a high article ID included the a collection of 
synchronized article ID ranges represented in the community range field. 

NNTP shows a community range field representing a collection of article ID 
ranges from a news group community that have been synchronized with community 
header properties {9.5. 1. 1); 

a low article ID field representing a low article ID included the a collection of 
synchronized article ID ranges represented in the community range field {9.1.1.1); and 

a high article ID field representing a high article ID included the a collection of 
synchronized article ID ranges represented in the community range field {9. 1. 1. 1). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck with that of NNTP in order to utilize a 
standard protocol for the purpose for which it was designed (that is, use Network News 
Protocol to process and manage network news). 
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56. Claims 1 2 - 1 6, 45, 48 and 50 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Guck in view of Lewis (US 2003/0109271 A1). 

57. Regarding claim 1 2, Guck shows an act of supplementing the message item with 
additional data to make the message item further compatible with at least one additional 
message protocol or additional message application, including (Guckl, Fig. 5E item 

1 13, col. 2 lines 30 - 35, col. 9 lines 25 - 32, Guck2, col. 4 lines 17-30, col. 14 lines 15 - 
65, col. 15 lines 64-65): 

an act of, subsequent to message creation, accessing the message item (Guckl, 
col. 7 lines 59-61, col. 9 line 51 - col. 10 line 5); 

and act of the processor snapping on data fields from a further message 
extension schema to the message item {Guckl, col. 9 lines 20-35, Fig. 3C items 53 - 
57), the data fields in the further message extension schema having one or more new 
properties that are to be associated with the message item to facilitate compatibility with 
the additional message protocol {Guckl, col. 10 line 50- col. 11 line 4, Guck2, col. 13 
lines 61-63, col. 14 lines 23-35); 

an act assigning properties such that the message item is compatible with the 
additional message protocol or additional message application such that the message 
item contains data making it compatible with the plurality of different message protocols, 
the plurality of different message applications and the additional message protocol or 
additional message application (Guckl col. 6 lines 54-58, Guck2, col. 4 lines 14-38, 
col. 7 lines 45 - 54, Guck3 lines 35 - 44). 

Guck does not explicitly show all of: an act of retrieving at least one value from 
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one or more other data fields attached to the message; and 

an act of assigning the retrieved at least one value to at least one of the snapped 
on data fields to make the message item compatible with the additional message 
protocol or the additional message application. 

Lewis shows an act of retrieving at least one value from one or more other data 
fields attached to the message; and 

an act of assigning the retrieved at least one value to at least one of the snapped 
on data fields to make the message item compatible with the additional message 
protocol or the additional message application {[123-127, 139, 161-166]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck with that of Lewis in order to improve 
message storage and retrieval to better handle the wide variety of formats commonly 
encountered by users {Lewis, [10]). 

58. Regarding claim 1 3, Guck in view of Lewis further show wherein the act of 
accessing the message item comprises an act of accessing a message item 
representing the electronic message, the message item having the one or more general 
properties that are common to the plurality of different message protocols and the 
plurality of different message applications {Guckl, Fig. 3C, col. 7 lines 59 - 61, col. 10 
lines 48 - 50, Guck2, col. 10 lines 48 - 49). 

59. Regarding claim 1 4, Guck in view of Lewis further show wherein the act of 
snapping on data fields defined in a further message extension schema to the message 
item assigning a new message extension to the message item comprises an act of 
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snapping on data fields from a further message extension schema, the new-further 
message extension schema being selected from among electronic mail protocol 
extension schemas, instant messaging protocol extension schemas, fax protocol 
extension schemas, voice message protocol extension schemas and, news group 
posting protocol extension schemas, electronic mail application extension schemas, 
instant messaging application extension schemas, fax application extension schemas, 
voice message application extension schemas, and news group posting application 
extension schemas (Guckl, col. 5 lines 1 - 25). 

60. Regarding claim 1 5, Guck in view of Lewis further show wherein an act of 
retrieving at least one value from other data fields attached to the message comprises 
on act of retrieving values from one or more data fields of a message item that 
represents one of an electronic mail message, a fax message, an instant message, a 
voice message, or a news group posting (Guck2, col. 15 lines 14 - 35 and Guck3 col. 8 
lines 2- 13). 

61. Regarding claim 1 6, Guck in view of Lewis further show wherein the act of 
assigning the retrieved at least one value to at least one of the snapped on data fields 
new specific properties comprises an act of assigning a value retrieved from one-of-a 
data field defined in one of an electronic mail message extension schema, a fax 
message extension schema, an instant message extension schema, a voice message 
extension schema, or a news group posting extension schema, to a snapped on data 
field defined in one of an electronic mail message extension schema, a fax message 
extension schema, an instant message extension schema, a voice message extension 
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schema, or an assigned news group posting extension schema (Guck2, col. 14 line 15 - 
col. 15 line 67). 

62. Regarding claim 45, Guck shows computer executable instructions that, when 
executed, cause the computer system to perform (Guck2, col. 2 lines 20 - 32, col. 2 line 
67- col. 3 line 10, col. 6 lines 42 - 48) the following: 

subsequent to message creation, accessing the message item [Guckl, col. 7 
lines 59-61, col. 9 line 51 - col. 10 line 5); 

snap on data fields from a further message extension schema to the message 
item (Guckl, col. 9 lines 20- 35, Fig. 3C items 53 - 57), the data fields in the further 
message extension schema having one or more new properties that are to be 
associated with the message item to facilitate compatibility with the additional message 
protocol {Guckl, col. 10 line 50 -col. 11 line 4, Guck2, col. 13 lines 61 - 63, col. 14 
lines 23 - 35); 

an act assigning properties such that the message item is compatible with the 
additional message protocol or additional message application such that the message 
item contains data making it compatible with the plurality of different message protocols, 
the plurality of different message applications and the additional message protocol or 
additional message application (Guckl col. 6 lines 54- 58, Guck2, col. 4 lines 14- 38, 
col. 7 lines 45 - 54, Guck3 lines 35 - 44). 

Guck does not explicitly show all of: an act of retrieving at least one value from 
one or more other data fields attached to the message; and 

an act of assigning the retrieved at least one value to at least one of the snapped 
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on data fields to make the message item compatible with the additional message 
protocol or the additional message application. 

Lewis shows an act of retrieving at least one value from one or more other data 
fields attached to the message; and 

an act of assigning the retrieved at least one value to at least one of the snapped 
on data fields to make the message item compatible with the additional message 
protocol or the additional message application ([123-127, 139, 161-166]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck with that of Lewis in order to improve 
message storage and retrieval to better handle the wide variety of formats commonly 
encountered by users {Lewis, [10]}. 

63. Regarding claim 48, Guck in view of Lewis further show wherein the act of 
snapping on fields from a further message extension schema to the message item 
comprise act of {Guck2, col. 7 lines 14-42) snapping on (Guck2, col. 14 lines 23 - 25) 
fields from an instant message (Guck2, col. 15 lines 5- 10, Guckl, col. 9 lines 1- 30) 
application extension schema to a message item that is currently compatible with an 
electronic mail message application (Guck2, col. 15 lines 50-65); and 

wherein the act of assigning the retrieved at least one value to at least one of the 
snapped on data fields to make the message item compatible with the additional 
message protocol or the additional message application comprises an act of {Guck2, 
col. 7 lines 14 - 42) assigning the retrieved value to least one data field snapped on 
from the instant message application extension schema to make the message item 



Application/Control Number: 10/692,097 Page 36 

Art Unit: 2442 

compatible with both an instant message application and the electronic mail message 
application (Guck2, col. 15 lines 27- 45). 

64. Regarding claim 50, Guck in view of Lewis further show wherein the act of 
snapping on fields from a further message extension schema to the message item 
comprise act of {Guck2, col. 7 lines 14 - 42) snapping on fields {Guck2, col. 14 lines 15 - 
25) from one of: a fax protocol schema and a voice message protocol schema to a 
message item that is currently compatible with an electronic mail message protocol 
{Guck2, col. 14 lines 15-26, col. 15 lines 50 - 65); and 

wherein the act of assigning the retrieved at least one value to at least one of the 
snapped on data fields to make the message item compatible with the additional 
message protocol (Guck2, col. 7 lines 14-42) or the additional message application 
comprises an act of assigning the retrieved value to least one data field snapped 
{Guck2, col. 14 lines 15 - 26) on from the one of the fax protocol schema and the voice 
message protocol schema to make the message item compatible with the electronic 
mail protocol and one of a fax application and a voice message application 
corresponding to the fax protocol schema and the voice message protocol schema 
respectively {Guck2, col. 7 lines 37- 42, col. 8 lines 10 - 35, col. 15 lines 50 - 65). 

65. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Guck in 
view of Lewis and Yost (6,260,050 B1 ). 

66. Regarding claim 49, Guck in view of Lewis show claim 1 2, including wherein the 
act of snapping on fields from a further message extension schema to the message 
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item comprise act of {Guck2, col. 7 lines 14 - 42) snapping on fields {Guck2, col. 14 
lines 23 - 25) from an electronic mail message application schema as well as a 
message item that is currently compatible with first electronic mail message application 
{Guck2, col. 15 lines 50 - 65 and Fig. 1 item 30); and 

wherein the act of assigning the retrieved at least one value to at least one of the 
snapped on data fields to make the message item compatible with the additional 
message protocol or the additional message application comprises an act of assigning 
the retrieved value to least one data field snapped on from the electronic mail message 
application extension schema (Guck2, col. 7 lines 14 - 42). 

Guck in view of Lewis do not explicitly show all of: compatibility with both a 
second electronic mail message application and a first electronic mail message 
application. 

Yost shows show compatibility with both a second electronic mail message 
application and a first electronic mail message application {col. 4 lines 1 - 15, col. 6 
lines 27- 32). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the disclosure of Guck in view of Lewis with that of Yost in order to 
readily adapt output forms to any type of electronic device, further improving and 
broadening compatibility {Yost, col. 3 lines 58 - 67). 
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Conclusion 

The following prior art made of record and not relied upon is considered pertinent 
to applicant's disclosure: 

US 2002/0133568 A1 SMITH 09-2002 

US 2004/0205731 A1 JUNKERMAN 10-2004 

Smith shows a method for managing multiple types of message applications and 
message protocols through the use of a common-underlying format (XML). 

Junkerman also shows managing multiple message protocols utilizing by XML, 
including extracting message parameters based on message input and inserting 
message parameters and message data based on the desired message output. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to John M. Macllwinen whose telephone number is (571) 
272-9686. The examiner can normally be reached on M-F 7:30AM - 5:00PM EST; off 
alternate Fridays. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glen Burgess, can be reached on (571) 272 - 3949. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

John Macllwinen /KEVIN BATES/ 

Primary Examiner, Art Unit 2456 

(571) 272 - 9686 



